ВНЕЗАПНО, немного про метрики. Обычно для отслеживания работы приложений мы используем несколько приёмов:

1. Тащим все количественные штуки, которые можем найти в приложении
Количество свободных подключений в пуле БД или чём-то подобном, процент попадания в кеш, количество запросов и прочее.
Во многих случаях «ручки» для мониторинга предусмотрены заранее или даже вытащены производителями фреймворков наружу. Например, в Spring Boot можно получить инфу о состоянии пула БД.

2. Тащим временные метрики
С ними чуть сложнее. Нужно обмазывать метриками вручную каждый функциональный уровень (слой, если хотите) условной аннотацией @Timed:
— Контроллер (обычно в том же спринге метрики выведены)
— Сервисы уровня приложений
— Все внешние адаптеры, не важно, куда мы ходим, в БД или внешнюю систему

3. Тащим количество событий предметной области по каждому из типов
Служит косвенным признаком, что с системой всё хорошо. Технически всё может быть исправно, но по какой-то причине пользователи перестали жмакать кнопки, по количеству событий можем заметить, что что-то не так.

Итого, это необходимый минимум метрик для наблюдений за приложением (ну, помимо стандартных CPU и прочего). Можно раньше пользователей увидеть, что что-то идёт не так. Также можно профилировать, гонять нагрузочные тесты и хотя бы примерно понимать, где тормозит.

Есть и более хардкорный вариант — непрерывное профилирование, когда профайлинг идёт в реальном времени и можно увидеть, где, что и сколько выполнялось, примерно как в обычной IDE. Если у вас нагруженное приложение, можно попробовать эту практику, вместо того чтобы спрашивать у админов «а чо как мне тут агента подсунуть, профайлить хотим».

Как я получал оффер от банка

В Thoughtworks меня только-только сократили, я написал в LinkedIn, что я бедный и несчастный, ищу работу, и лёг спать.

В 11:00 следующего дня в телеграме мне пишет неизвестный: «я не знаю кто ты, но я тебя найду уже 3 человека сказали, что я обязан с тобой поговорить. Если нужна работа, приезжай в офис».

Первым рекомендателем оказался мой бывший коллега, Thoughtworker старой закалки. Он перешёл в этот банк несколько лет назад. Увидел мой пост и с утра пошёл к СТО сказать, что есть я, которого ещё вчера Thoughtworks предлагал им взять в аренду в 2 раза дороже, чем я сегодня стою.

Второй — мой знакомый, с которым мы жарили шашлыки и пили пиво. Тоже увидел мой пост и за утренним кофе тому же СТО сказал, что было бы неплохо меня нанять.

Но их всех опередил мой бывший проджект-менеджер, который решил позвонить этому СТО ещё вечером накануне.

В итоге я пришёл на собеседование, где мне час рассказывали, как в банке что устроено, какие есть проблемы и как они видят будущее. Я сидел и думал, когда же начать рассказ о себе. Но хвататься расхотелось, когда СТО пожаловался, что обо мне ему уже все рассказали, и не один раз. Но бедный СТО не знал, что на следующий день его ждёт встреча с Омаром — директором финсектора Thoughtworks. Драматизм ситуации в том, что это человек, который может продать что угодно кому угодно. И именно у Омара я научился отвечать на вопросы клиента, когда напрямую ответить нельзя, и заражать клиента своими идеями. Омар встретился с СТО по другому вопросу, но тоже между делом искренне меня рекомендовал, так что у банка шансов не оставалось.

Вывод: личные контакты решают. Если у вас проблема — расскажите о ней, и помощь может прийти оттуда, откуда не ждали.

Пока Сережа наслаждается успехом, мы снова возвращаемся к духоте.

Коллеги скинули всё ещё актуальную заметку про предварительный анализ. Не обращайте внимания на название, суть там в другом — перед тем как что-то реализовывать, это стоит описать в доке.
Например:
— какие изменения нужно внести
— какие будут контракты
— как лучше тестировать
— etc

Я сам исповедую примерно такой подход уже в нескольких конторах. Кажется, что это бюрократия и трата времени, но в итоге у всех участников выравнивается понимание конечного результата. Особенно когда такая дока пишется сообща. Тестеры понимают, как тестить, разрабы понимают, как ревьювить и т.д. Метод сильно отличается от классического «вот вам задача в жыре, сами понимайте, что я тут имел ввиду, вы ж умные»

В итоге количество непоняток и переделок снижается в разы, легко организовать трассировку, а разработчики уходят с полным пониманием задачи и повышается точность прогнозирования сроков в сторипоинтах.

Что ещё можно добавить в такую доку?
— контекст: зачем мы вообще это делаем, какую задачу решаем
— модель предметной области на основе Event Storming
— use case и альтернативные сценарии
— макеты в Фигме
— какая документация должна родиться
— какие метрики нужно вывести
— какие алерты настроить
— что поменяется в инфраструктуре
— риски безопасности
— любые другие технические подробности
— ссылки на другие документы

Несколько важных наблюдений

1. Документ обычно описывает ближайшую задачу, никаких «на вырост». Версии тут как таковых нет, потому что мы очень плохо можем в дифф.

2. Документ обычно пишется на пользовательскую историю или похожий артефакт, то есть в изготовлении доки задействуются и фронтендеры и бекендеры и тестировщики, которым это потом чинить. Далее сторя разбивается на подзадачи для конкретных спецов. Фактически мы начинаем разрабатывать на бумаге, продумываем самые сложные сценарии, а кодить можно уже спинным мозгом. В этом отличие от классических требований (даже самых подробных) описываемых аналитиками.

3. Документирование может отмереть, если команда нарастит квалификацию и достаточно сработается. Это нормально, потому что цель — не бумажка, а общее понимание результата.

4. Подход слабо работает в лапшекоде уровня «после просмотра промыть глазаа хлоргексидином», ибо количество непредвиденных ситуаций ломает начальную идею полностью. Хотя полностью от них избавиться не получится даже в поддерживаемом коде

Практикуете на работе? Микросервисы уже внедрили?🙂

Сергей на связи!
На новой работе увидел интересный приём, которым архитекторы кошмарят разработчиков. Спешу поделится.

Значит, у архитектора есть 2 большие задачи.

Задача раз: выработать нефункциональные требования, а потом на их основе нарисовать архитектуру. Задача сложная, но с ней более-менее большинство справляется.
Задача два: проследить, чтобы команда соблюдала заложенные в архитектуру принципы. С этим справляются уже не все, зачастую фантазии хватает только разносить всех на code review. Если у архитектора команда на 5-7 разработчиков, то так прожить ещё можно. А если у вас целый департамент на 50-70 программистов — ну такое.

Конечно, нужно автоматизировать битьё разработчиков по рукам. Например, автоматически проверять % покрытия тестами, или code style. Как правило, они интегрируются в систему сборки и запускаются автоматически, заваливая билд, если какая-то договорённость не соблюдена.

Но если репозиториев уже под сотню, и они плодятся каждый день? Тогда следить за соблюдением договорённостей помогает вот это:
— везде интегрирован jacoco, который проверяет покрытие тестами хотя бы 80%
— во всех репозиториях используется один code style
— все зависимости тянутся только из внутреннего репозитория

Делюсь подсмотренным приёмом: использовать стандартизированный gradle. Как правило, любая сборка состоит из интегрированных плагинов, конфигурация которых вручную копируется из одного проекта в другой. Но можно сделать собственный gradle wrapper со всеми установленными и настроенными плагинами.

Как работает
Архитектор один раз создёет репозиторий, который будет билдить gradle wrapper. Он публикуется в артифактори и становится доступен для скачивания как обычный пакет.

Далее архитектор создает обычный файл build.gradle, добавляет зависимости по вкусу, типа спринга или junit, и настраивает плагины, к примеру, jacoco. Зовётся это init scripts. Архитектор публикует грейдл, рассылает всем разработчикам ссылку на него и идёт спокойно пить пиво. Теперь разработчики при создании проекта указывают, что wrapper надо скачивать не с gradle.org, а из вашего репозитория.

gradle-wrapper.properties
distributionUrl=https://artifactory.your.org/repository/gradle-8.5.zip

Профит! Теперь в проект интегрировано всё минимально необходимое.

Фича зовётся gradle init scripts

Минусы
Если вдруг политики поменялись, скажем, мы резко захотели добавить какой-нибудь security плагин, то пока проекты не обновят версию грейдла, никакого чуда не произойдёт.

Первые впечатления от работы

Ситуация. Разрабатываем anticorruption layer между бравыми цифровыми сервисами банка и глючным core. Проекту три месяца. У всех разработчиков опыта минимум 7 лет. Из репозитория машет маленький-жук навозник, почти свалявший себе шарик говна. Буду вести репортаж, как мы всё это будем пересаживать на рельсы clean architecture.

Пока план такой:
1. Понять, как должно быть, и насколько мы далеки от этого
2. Найти единомышленников или хотя бы неравнодушных
3 .Разработать план рефакторинга, включив туда как можно больше людей. Чтобы все были повязаны и не саботировали потом.
4. Запихнуть задачи на рефакторинг в ближайшие спринты. Чего ждать.

На следующей неделе расскажу, как пошло.

Нам писали, что курс «Поваренная книга дядюшки Боба» тормозит. Докладываю: курс перезалит, теперь можно смотреть без регистрации, VPN и тормозов. Даже с мобилы.

Ну вы поняли как действовать!

Почему агрегаты должны хранить свои секреты

Когда в чате обсуждают агрегаты, то в первую очередь упоминают инварианты и транзакционные границы, но есть еще один критический аспект, который нельзя игнорировать: сокрытие деталей внутренних сущностей. Агрегаты должны быть не просто контейнерами для реализации бизнес-правил - они также должны защищать свою внутреннюю структуру. Одна из важнейших функций агрегата - обеспечить, чтобы его внутренние сущности и объекты значений не использовались (и тем более не изменялись) внешним кодом. Например, агрегат Order может содержать список элементов Product. Вместо того чтобы разрешать доступ, например order.Products.Add(product), лучше добавить метод order.AddProduct(product).

Почему? Потому что таким образом агрегат контролирует все необходимые проверки и пересчеты внутри себя. Это сохраняет логику последовательной, гарантируя, что когда нам надо пересчитать что-то вроде TotalPrice, то мы сделаем это в одном месте и сразу для всех. Внешний код не должен знать, как именно это делается. Но это не все, самое важное:

Сохранение секретов == гибкость

Когда агрегаты скрывают свою внутреннюю структуру, наша система становится гораздо более гибкой. Вы можете рефакторить внутрянку, не переживая за другие части кодовой базы. Внешние компоненты взаимодействуют с агрегатами через четко определенный интерфейс (aggregate root, корень агрегата), что делает наш код более устойчивым к изменениям.

Таким образом, скрыв внутренние детали, мы можем сосредоточиться на основных обязанностях агрегатов: выполнении бизнес-правил и поддержании согласованности. В результате, мы не только снижаем сложность, но и повышаем гибкость и поддерживаемость нашей доменной модели, облегчая реализацию будущих изменений.

Антипаттерн «Кадастровый инженер»

Хочет всё размежевать, чтобы не слиплось. Считает, что разделение по репозиториям и приложениям — панацея от скверны лапшекода. Мол, щас всё растащим, и никто не сможет использовать Х в У.

Такой подход работает, но, как всегда, есть нюанс: можно ошибиться с границей разрезания. Например, нарезать не там в микросервисах, и получим неподдерживаемое распределённое нечто.

Крайнее проявление — вынести в отдельный репозиторий каждый компонент единой системы: тесты, вёрстку, сервисы, скрипты миграций и т.д. Тогда вашей работой становится жонглирование ветками и толкание локтями коллег в репозиториях в попытках собрать всё воедино хотя бы на CI-сервере.

Чтобы разрез сильно не болел, нужно научиться искать логические границы и уметь пресекать нарушения. Потом дать границам устояться, и только потом отрезать. Попытка что-либо отрезать в бардаке приводит к ещё большему бардаку.

Как понять, что разделили неправильно? Когда для одной задачи вам приходится коммитить сразу в несколько репозиториев и в строгой последовательности. У репозиториев оказался слишком высокий coupling. Да, представьте coupling и cohesion применим и в рамках git-репозитория.

Небольшая заметка о стрессоустойчивости и вреде гиблых проектов https://vk.com/@-200496256-timlid-ozverel

Ребята из Postgres Professional написали неплохую книгу «PostgreSQL 16 изнутри»

Какие темы охватывает книга:
— Устройство shared buffer
— Как работает WAL
— Как выполняются запросы
— Зачем нам вакуум
— Как работают индексы
— Как устроен MVCC
— etc

Всего 665 страниц годноты на русском. Кому лень читать — у ребят есть ютуп-канал, посвящённый той же теме

Просвещайтесь!

#полезнота

Последние несколько месяцев слышал от разных людей (у нас и за границей) похожие истории про техдолг:

Не можем получить новую фичу вообще никак. Сроки просраны, а результат не предвидится. Заливание баблом, джунами и индусами больше не работает. Начальство в бешенстве, переписывать нет времени, что делать — не понятно.

В общем, долго клали болт на соответствие потребностей и реализации, и вот вдруг ВНЕЗАПНО что-то пошло не так.

Возможно, это явление массовое и происходит от общепринятого подхода в индустрии: да пофиг ваще, бизнес бабки колотит, остальное похер. В ключевых системах ожидаемо накопилась критическая масса, и техдолг начал стрелять у всех. Ну или это просто совпадение.

Происходит ли у вас что-то подобное? Поделитесь, нам важно это знать :3

К посту про SQL. Пока лазил на сайте Postgres Professional, наткнулся ещё на одну интересную книгу — «Путеводитель по базам данных».

Что внутри:
— Какие структуры данных используются для построения СУБД
— На каких алгоритмах построены распределённые СУБД
— Репликация и бекапы
— Журналирование
— Управление доступом

Для хардкорщиков, сохраняющих петабайты транзакций в наносек, будет не очень интересно, а вот для спецов среднего уровня и выше или для тех, кто хочет систематизировать знания и закрыть пробелы, — самое то.

#полезнота

На следующей неделе планируем провести стрим на тему «Внедрение DDD на практике — профиты и проблемы».

К нам в гости придет наш товарищ Константин Шибков, старший Java разработчик СДЕК, автор курсов и статей по разработке, соорганизатор митапа про бережливые бизнес процессы AgileUfa и клуба разработчиков JavaKeyFrames.

Мы обсудим как Константин внедрял архитектурные подходы и паттерны и узнаем, что из этого вышло.

Ссылку пришлем позже, приходите и задавайте вопросы 🙂

Предварительно, запланировали стрим в четверг 31 октября в 18:00 МСК

Напоминаем, что сегодня состоится встреча. Ссылку скинем перед началом. Не пропустите!

Погнали! https://youtube.com/live/HYI5XzQFE3U?feature=share

Мы не знаем кто автор, но это просто шедеврально

Нас много раз спрашивали как удобнее всего обрабатывать ошибки и исключения. Рассказываем, как мы это делаем и почему стандартный try-catch не всегда удобен.

Если видос показался полезным — поделитесь с братюнями. И подпишитесь на канал, конечно же

Приятного просмотра!